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ABSTRACT 


Current  methods  of  developing  user  interfaces  for  IRIS 
workstation  application  programs  are  inefficient.  In  order 
to  help  speed  the  development  of  complex  graphics  programs, 
IRIS  workstation  users  need  a  toolkit  that  will  assist  in 
the  design  and  implementation  of  user  interfaces  for 
graphics  programs.  This  project  presents  the  preliminary 
work  on  an  interface  generator  for  the  Silicon  Graphics, 
Inc.  IRIS  workstation.  The  NPS  Interface  Builder  (NPS  IB) 
is  designed  to  speed  the  creation  of  application  programs  by 
allowing  a  user  to  define  an  interface  graphically  rather 
than  by  writing  "C"  code.  The  program  provides  on-screen 
editing,  facilitated  by  a  number  of  program  features. 
NPS  IB  can  be  user  to  develop  the  basic  framework  of  a 
graphics  program,  or  can  be  user  to  enhance  the  capabilities 
of  an  already  existing  graphics  application. 
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I. 


NEED  FOR  AN  INTERFACE  SYSTEM 


This  project  is  the  preliminary  work  on  an  interface 
generator  for  the  Silicon  Graphics,  Inc.  IRIS  workstation. 
The  result  of  this  project  is  the  NPS  Interface  Builder  (NPS 
IB) ,  which  is  designed  to  speed  the  creation  of  application 
programs  by  allowing  a  user  to  define  an  interface 
graphically  rather  than  writing  "C"  code.  The  development 
of  the  NPS  IB  represents  a  unique  departure  from  previous 
methods  of  user  interface  development.  This  is  because  the 
NPS  IB  is  capable  of  converting  a  user-specified  picture 
into  usable  "C"  code. 

A.  CURRENT  INTERFACE  DESIGN  METHOD 

Design  of  a  user  interface  represents  a  considerable 
time  investment  for  programmers.  For  some  programmers,  user 
interface  concerns  can  mean  an  unwelcome  diversion  of  time 
and  energy  away  from  an  application  program.  Besides 
considering  how  the  user  interface  should  look,  the  program 
developer  has  to  produce  the  actual  implementation  by 
writing  original  "C"  code  routines  to  draw  the  interface  and 
produce  the  interaction  between  interface  and  program.  This 
methodology  is  grossly  inefficient,  since  it  means  that  each 
user  wishing  to  develop  a  graphics  program  for  the  IRIS 
workstation  must  essentially  reinvent  the  wheel  by  coding 
his  own  interface.  In  addition  to  being  inefficient,  this 
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method  of  programming  results  in  a  wide  disparity  in  the 
appearance  of  user  interfaces  across  graphics  programming. 
To  an  end-user,  each  graphics  program  presents  a  new  and 
different  set  of  interface  challenges  to  master. 

Certain  types  of  interface  controls  seem  to  remain 
constant  throughout  graphics  programs.  Sliders  are  used  to 
rotate,  scale,  or  translate  objects.  Checkboxes  are  used  to 
indicate  that  some  function  should  be  performed,  such  as 
printing  data  or  verifying  information.  Dials  can  be  used 
to  represent  mechanical  devices  such  as  a  shipboard  rudder 
angle  indicator.  Although  the  uses  of  the  controls  can  vary 


from  program 

to 

program,  the  basic 

operating  mechanisms 

remain  the 

same. 

This  is  what  makes  it 

possible 

to 

incorporate 

these 

controls  into  a 

standard 

library 

of 

controls.  With  the  addition  of  routines  to  specify  the 
placement  and  checkout  of  the  controls,  an  interface  builder 
for  the  IRIS  workstation  is  born.  The  use  of  an  interface 
builder  can  result  in  a  considerable  time-savings  for  the 
application  programmer,  and  its  use  of  a  standard  set  of 
controls  has  the  potential  to  relieve  the  problems  caused 
for  end-users  by  the  large  numbers  of  disparate  interfaces 
that  currently  exist  in  graphics  programming. 

B.  DEVELOPMENT  OF  INTERFACE  BUILDERS  AND  TOOLKITS 

Increase  in  the  memory  capacity  of  modern  computers  has 
been  accompanied  by  a  corresponding  increase  in  the 
sophistication  and  size  of  application  programs.  As  the 
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capabilities  of  the  computer  have  expanded,  end-users  have 
demanded  software  that  best  utilizes  the  powers  and 
abilities  of  their  machines.  This  has  resulted  in  an 
explosion  of  large,  complex  programs  with  highly 
sophisticated  user  interfaces.  Often  these  programs  are  of 
such  size  and  complexity  that  they  are  beyond  the 
capabilities  of  just  one  person  to  write  and  debug. 

Computer-aided  software  engineering  is  intended  to 
reduce  the  time  needed  to  create  a  software  application, 
while  at  the  same  time  improving  the  quality  of  the  software 
produced.  Reference  1  notes  that  the  definition  of 
computer-aided  software  engineering  includes  the  use  of 
tools  which  provide  leverage  at  any  point  in  the  software 
development  lifecycle.  Interface  generators,  like  the  NPS 
IB,  provide  leverage  in  both  the  design  and  implementation 
phases  of  the  lifecycle  by  allowing  a  designer  to  visually 
develop  the  interface  and  then  automatically  create  the  code 
for  it. 

Interface  generators  are  also  valuable  tools  for 
prototyping.  Prototyping  permits  a  software  developer  to 
quickly  build  an  executable  system  which  may  not  be 
complete.  This  system  can  then  be  demonstrated  to  users  and 
subsequently  can  be  easily  modified  if  required. 
Prototyping  saves  time  and  money  by  permitting  modifications 
to  a  system  before  the  implementation  phase  of  the  software 
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lifecycle.  An  interface  generator  such  as  the  NPS  IB  can 
provide  prototyping  capability. 

Interface  generators  are  available  commercially  for 
nearly  every  computing  machine  on  the  market.  Such  systems 
include  Interface  Builder,  which  permits  users  to  build 
interfaces  for  application  programs  on  the  Next  computer 
[Ref.  2],  and  C-scape  [Ref.  3],  which  permits  users  to 
create  custom  interfaces  for  personal  computers.  In 
addition,  several  interface  generators  and  toolkits  have 
been  developed  specifically  for  the  IRIS  workstation  family 
of  computers.  These  include  the  following  packages. 

1  •  Dialogue  Management  System  (DMS) 

Reference  4  reports  on  an  experimental  research 
project  at  Virginia  Tech  called  the  Dialogue  Management 
System.  Developed  for  the  Silicon  Graphics  IRIS  2400 
workstation,  DMS  is  described  as  a  comprehensive  system  for 
interface  management.  The  system  is  comprised  of  three 
components,  including  a  dialogue  component  which  provides 
for  interaction  between  an  end-user  and  the  application 
program,  a  computational  component,  which  contains  all 
semantic  processing  algorithms,  and  a  global  control 
component,  which  manages  sequencing  between  the  dialogue  and 
computational  components.  DMS  provides  for  interactive 
development  of  all  three  components,  including  a  tool  for 
direct  manipulation  of  graphical  objects  when  developing  an 
interface.  The  developers  of  DMS  report  that  this 
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tool-based  approach  is  much  faster  than  conventional  source 
coding.  In  fact,  they  say,  the  use  of  DMS  for  implementing 
an  interface  provides  a  nearly  four-to-one  improvement  in 
speed  over  the  use  of  programming  for  developing  the  same 
interface. 

2 .  NASA  Ames  Panel  Package 

The  NASA  Ames  Panel  Package  was  developed  by  David 
Tristram  at  NASA  Ames  Research  Center  [Ref.  5],  The  package 
is  public-domain  software,  and  provides  a  user-interface 
toolkit  for  the  Silicon  Graphics  family  of  workstations. 
The  Panel  Package  provides  a  panel  library  consisting  of 
actuators,  which  are  controls  such  as  dials  or  sliders,  and 
panels,  which  contain  groups  of  actuators.  Demonstration 
programs  created  using  the  panel  package  show  that  the 
package  is  a  very  powerful  and  professional-looking  toolkit. 
Unfortunately,  use  of  the  panel  package  relies  upon  an 
understanding  of  package  features,  as  well  as  a  good 
understanding  of  the  "C"  programming  language.  Reference  3, 
which  is  the  documentation  manual  for  the  panel  package,  can 
help  a  user  get  started.  The  time  overhead  required  to 
learn  the  system  does  not  offset  the  usefulness  of  the 
package.  But  the  speed  of  producing  an  interface  must 
inherently  be  slower  than  methods  such  as  DMS  since  the  user 
must  deal  directly  with  raw  code. 
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3 .  Slider  and  Button  Package 


The  Slider  and  Button  (S  &  B)  package  is  a  tool  for 
providing  windows  of  sliders  and  buttons  only  on  the  Silicon 
'raphics  IRIS  4D  workstations.  The  S  &  B  package  consists 
of  support  routines  which  open  a  graphics  window,  draw  the 
buttons  and  sliders,  and  provide  the  interaction  mechanism 
between  the  controls  and  the  end-user.  The  S  &  B  package  is 
quick  and  easy  to  use.  The  application  programmer  does  not 
have  to  understand  detailed  operation  of  the  package  to  use 
it.  In  this,  the  S  &  B  package  can  realize  a  considerable 
time-savings  for  the  programmer. 

4 .  NPS  Interface  Builder 

The  NPS  IB  is  the  product  of  this  study.  It  was 
designed  to  help  speed  the  creation  of  application  programs 
by  allowing  a  user  to  define  an  interface  graphically  rather 
than  writing  "C"  code.  The  program  allows  a  designer  to 
select  interface  controls  from  a  standard  set  of  controls, 
and  to  interactively  specify  the  placement  of  those  controls 
in  a  graphics  window.  The  NPS  IB  produces  as  output  the 
skeleton  of  a  graphics  program,  written  in  "C"  code,  with 
designer-specified  controls  in  place.  The  application 
programmer  then  builds  his  program  upon  this  interface 
foundation.  The  NPS  IB  program  can  save  time  and  effort  for 
an  application  programmer,  since  it  generates  "C"  code  from 
a  programmer-specified  picture. 
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C.  NAVAL  POSTGRADUATE  SCHOOL  GRAPHICS  AND  VIDEO  LABORATORY 


The  Naval  Postgraduate  School's  Graphics  and  Video 

Laboratory  has  been  developed  for  use  by  students  in 
beginning  graphics  courses  and  for  those  students  desiring 
to  pursue  master's  thesis  topics  in  graphics  or  graphics- 
related  areas.  The  equipment  currently  in  the  lab  consists 
of  two  Silicon  Graphics  IRIS-4D/120GTX  workstations  and  one 
IRIS-4D/70GT  workstation.  These  machines  support  project 
work  from  graphics  courses  as  well  as  research  work  for 
master's  thesis  topics.  The  NPS  IB  program  can  benefit 
graphics  course  students  and  thesis  research  students 
equally  as  well.  For  the  graphics  student,  NPS  IB  can 

produce  the  framework  for  a  first  graphics  program — a 

framework  upon  which  the  student  can  build  a  graphics 
project  as  his  learning  and  expertise  grow.  A  graphics 
thesis  student  might  use  the  NPS  IB  program  to  build 
supplemental  command  and  control  windows  for  a  thesis 
program. 

Thesis  students  using  the  Graphics  and  Video  Laboratory 
have  produced  many  visual  simulators  for  various  Department 
of  Defense  interests.  These  projects  have  included  the 
Fiber  Optic  Guided  Missile  (FOGM) ,  which  modeled  the  flight 
of  a  missile  over  the  terrain  of  Fort  Hunter  Liggett, 
California,  and  the  Moving  Platform  Simulator,  which 
featured  the  display  of  moving  vehicles  over  terrain  at  Fort 
Hunter  Liggett.  These  are  just  two  examples  of  thesis 
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programs  which  could  have  benefited  from  use  of  the  NPS  IB 
program. 

D.  SUMMARY  OF  THE  CHAPTERS 

The  remainder  of  this  study  discusses  design  and 
implementation  issues  considered  in  creating  NPS  IB. 
Chapter  II  provides  an  overview  of  the  NPS  IB,  from  its 
operating  environment  to  program  features.  Chapter  III 
discusses  program  specifics  including  graphics  support  and 
implementation  considerations.  Chapter  IV  discusses 
operation  of  the  program  message  buffer.  Chapter  V  focuses 
on  the  format  of  NPS  IB  output,  along  with  the  routines  that 
produce  the  output.  Chapter  VI  contains  conclusions, 
limitations,  and  future  directions. 
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II.  NPS  INTERFACE  BUILDER  PROGRAM  DESCRIPTION 

A.  SYSTEM  OVERVIEW 

The  NPS  IB  is  a  menu-driven  program  consisting  of  a 
design  window,  a  control  palette  window,  and  a  message  and 
instruction  window,  shown  in  Figure  2.1.  The  design  window 
represents  the  application  programmer's  easel,  of  sorts, 
joon  which  the  layout  of  the  user  interface  is  designed. 
The  control  palette  window  contains  representations  of  the 
user  interface  controls  from  which  the  application 
programmer  can  choose.  The  message  and  instruction  window 
provides  messages  that  confirm  menu  choices  and  that  offer 
instructional  help  designed  to  guide  the  programmer  through 
use  of  the  program.  The  design  window  offers  a  resize 
option  so  that  the  user  can  alter  window  size.  The  control 
palette  and  the  message  buffer  windows  are  moveable  and  can 
be  placed  as  the  user  desires.  A  sample  rearrangement  is 
depicted  in  Figure  2.2. 

To  design  a  user  interface,  the  application  programmer 
chooses  the  edit  design  feature  from  the  selection  menu.  A 
control  can  then  be  selected  from  the  control  palette 
window.  The  system  asks  the  user  to  give  the  control  a  name 
and  to  specify  any  additional  maximum,  minimum,  or  initial 
values.  The  system  then  draws  a  floating  picture  of  the 
control  in  the  middle  of  the  design  window.  The  programmer 
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Figure  2.1  NPS  Interface  Builder  Program  Layout 


uses  the  mouse  to  maneuver  the  floating  control  about  the 
design  window,  allowing  the  determination  of  its  placement. 
To  drop  the  tool  into  its  place  in  the  window,  the 
programmer  clicks  the  middle  mouse  button,  and  a  fixed 
picture  of  the  control  is  drawn  in  the  location  specified. 
Figure  2.3  illustrates  the  design  window  with  one  fixed  tool 
in  place.  By  continuing  to  select  tools  from  the  tool 
palette  window  and  dropping  them  into  location  in  the  design 
window,  the  application  programmer  can  thus  build  a  complete 
user  interface.  An  interface  created  by  this  method  is 


shown  in  Figure  2.4. 


Figure  2.2  Sample  NPS  Interface  Builder  Window 
Rearrangement 

Menu  options  include  a  move  control  selection,  so  that 
positions  of  fixed  controls  can  be  altered  or  adjusted  if 
necessary,  and  a  delete  control  selection,  so  that  fixed 
controls  can  be  eliminated  from  the  design  window  entirely. 
The  run  controls  option  permits  the  programmer  to  test  the 
operation  of  controls  in  the  design  window.  The  reset 
selection  clears  all  fixed  controls  from  the  display  window 
without  saving  any  graphics  information  and  is  essentially 
akin  to  clearing  a  slate.  The  save  design  option  writes  the 
current  state  of  the  design  window  to  two  output  files — an 
ASCII  file  listing  of  graphics  information  for  each  control, 


Figure  2.3  Design  Window  with  Fixed  Control 


and  a  "C"  language  output  file  containing  the  skeleton  of  a 
graphics  program  that  the  user  can  compile,  link,  and 
execute.  A  sample  ASCII  file  listing  is  presented  in  Figure 
2.5,  while  a  sample  "CM  language  graphics  program  skeleton 
is  illustrated  in  Figure  2.6.  The  ASCII  file  output 
provides  the  NPS  IB  program  with  its  re-edit  capability. 
The  "C"  language  output  file  provides  the  user  with  a 
foundation  for  the  application  program. 
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/*  This  is  the  ASCII  output  file  for  a  window  created  with 
NPS  Interface  Builder  */ 

/*  save  the  window  size  */ 
lowerleftX  5 
lowerleftY  5 
upperrightX  1275 
upperrightY  1004 

/*  toggle  box  information  */ 

togglebox 

title  Cancel 

controlid  -1 

controlnum  1 

Xcoord  24.96 

Ycoord  30.56 

lowerleftxbound  23.78 

lower leftybound  29.31 

upper rightxbound  26.15 

upperrightybound  31.81 

togboxend 

/*  dial  information  */ 
dial 

title  Speed 
controlid  -4 
controlnum  2 
Xcoord  13.90 
Ycoord  49.20 
maximumvalue  50.00 
minimumvalue  0 . 00 
lov3rleftxbound  10.12 
lowerleftybound  45.19 
upperrightxbound  17 . 68 
upperrightybound  53.21 
dialend 

/*  vertical  slider  information  */ 

verticalslider 

title  Rotate 

controlid  -5 

controlnum  3 

Xcoord  27.52 

Ycoord  49.00 

maximumvalue  360.00 

minimumvalue  0.00 

startvalue  180.00 

lowerleftxbound  27.14 

lowerleftybound  41.48 

upperrightxbound  27.90 

upperrightybound  56.51 

vsliderend 

Figure  2.5  NPS  Interface  Builder  ASCII  File  Output  Listing 
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♦include" inter faceglobal . h" 

main ( ) 

( 

short  value; 
int  wintoken; 

maketogbutton ( "Cancel" , 24.96,30.56,23.78,29.31,26.15,31.81,1); 

makedial ("Speed", 13 . 90, 4 9 . 20, 10 . 12, 45 . 1 9, 1 7 . 68, 
53.21,50.00,0.00,0.00,0.00,1); 

makevslider  ( "Rotate" ,  27.52,49.00,27.14,41.48, 

27. 90, 56.51,0.00, 360.00, 180.00, 1) ; 

checkboxnum  «  2; 
dialnum  «•  2; 
vslidernum  -  2; 

/*  initialize  the  window  */ 

wintoken  -  initwindow  (  "custom  window" ,  5,  5,  12"’5,  1004  )  ; 

/*  enter  a  drawing  loop  */ 
while  (TRUE) 

( 

winset (wintoken) ; 

while  (qtest  ()  )  loop  while  there  is  something  on  the  queue 

I 

switch! qread(Svalue> ) 

( 

case  RET  RAW : 


winset  (wmtcken)  ; 
reshapeviewport  ()  ; 
wmccnstraints  ( !  ; 
update_mair._wir.dow  ( )  ; 
break ; 

case  LEETMOUSE : 

if  (value  —  1! 

( 

runcont  rolsl) ; 
drawpicture ( ) ; 
swaptuf  f era ( )  ; 

) 

break; 

case  P.1GHTMOUSE: 

break ; 

default : 

break ; 

I 

i 

drawp ict ure ( I ; 
swaptuf  fers ( ) ; 

I 


Figure  2.6  NPS  Interface  Builder  "C"  Language 
File  Output  Listing 
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III.  THE  NPS  INTERFACE  BUILDER  PROGRAM 


A.  DESIGN  ISSUES 

The  design  of  NPS  IB  encompassed  two  major  concerns. 
The  first  area  of  concern  involved  the  development  of  the 
user  inter  '.e  for  the  NPS  IB  program.  The  second  area  of 
concern  involved  the  actual  development  and  implementation 
of  the  program  itself,  including  data  structures  and 
routines  to  support  program  functionality. 

1 •  NPS  Interface  Builder  User  Interface 

References  7  and  8  were  consulted  in  an  attempt  to 
design  the  NPS  IB  program  user  interface  in  concert  with 
recommended  theories,  principles,  and  guidelines  of  user 
interface  design.  The  principle  of  consistency  was  the 
first  and  foremost  principle  considered,  followed  by  the 
ability  of  the  program  to  offer  informative  feedback  and  to 
offer  simple  error  handling.  In  addition,  two  interaction 
styles  were  defined  for  the  user  interface,  to  include  use 
of  program  menu  selections  and  direct  screen  manipulation  of 
objects  of  interest.  The  use  of  program  menu  selections 
structures  user  decision-making  and  supports  program 
consistency,  since  each  sequence  of  actions  in  the  program 
must  start  with  a  menu  selection.  Each  menu  selection, 
then,  is  followed  by  the  same  set  of  actions  in  each 
selection  category.  In  the  edit  design  mode,  for  example, 
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the  same  sequence  of  actions  is  followed  for  each  control 
selection:  pick  the  control  of  interest,  give  the  control 
name  and  value  attributes,  then  place  the  control  in  its 
desired  position  in  the  design  window. 

The  ability  of  the  program  to  offer  informative 
feedback  and  to  offer  simple  error  handling  is  made  possible 
by  both  menu  selection  and  direct  manipulation  of  objects  of 
interest.  Since  the  user  can  point  at  control  icons  and  can 
use  the  mouse  to  manipulate  icons  in  the  design  window,  the 
results  of  his  actions  are  immediately  observable.  Simple 
error  handling  is  provided  by  menu  selections  which  allow 
the  user  to  move  or  delete  control  icons  from  the  design 
window,  along  with  corresponding  direct  manipulation  of 
icons  to  be  moved  or  deleted.  User  feedback  is  also 
supported  by  the  message  buffer  window,  which  provides 
instructions  and  verification  information,  such  as 
confirmation  that  a  control  has  been  deleted. 

A  particular  design  issue  of  interest  was  the 
placement  of  the  cursor  and  the  floating  control  icon  after 
its  selection  from  the  control  palette  window  in  the  edit 
design  mode  option.  Originally,  the  program  design  called 
for  a  click  on  the  icon  drawing  of  interest  and  for 
subsequent  dragging  of  an  icon  clone  from  the  control 
palette  window  into  the  design  window.  It  was  discovered, 
however,  that  this  type  of  action  between  two  concurrently 
running  graphics  windows  was  quite  complicated,  and  the  idea 
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was  abandoned  in  favor  of  a  new  approach.  The  selected 
solution  to  the  problem  was  to  set  the  cursor  to  the  middle 
of  the  design  window  and  to  use  the  mouse  x  and  mouse  y 
coordinates  as  the  center  x  and  center  y  for  a  drawing  of 
the  floating  control.  The  user  could  then  use  the  mouse  to 
manipulate  the  cursor  about  the  design  window,  with  cursor 
movement  mirrored  by  the  floating  control  icon.  The  user  is 
not  as  likely  to  be  surprised  by  the  unexpected  cursor  jump 
from  the  control  palette  window  to  the  design  window,  since 
the  action  of  selecting  a  control  and  placing  it  in  the 
design  window  is  broken  up  by  the  program  request  for  user 
keyboard  input.  Since  the  user's  hand  must  leave  the  mouse 
to  operate  the  keyboard,  the  impact  of  the  cursor  jump  from 
control  palette  window  to  design  window  is  reduced 
considerably. 

2 .  NPS  Interface  Builder  Program  Design 

Three  issues  were  considered  in  designing  the 
structure  of  the  NPS  IB  program.  The  first  issue  was  that 
of  saving  graphics  information  for  each  control  placed  in 
the  design  window.  This  involved  selecting  an  appropriate 
data  structure  for  storing  a  variety  of  information  about  a 
single  control.  Data  structures  are  discussed  in  the  next 
part  of  this  chapter.  The  second  issue  considered  in 
designing  the  program  was  modularizing  the  program  so  that 
each  group  of  routines  in  a  single  file  performed  one  type 
of  functionality  for  the  program. 


18 


A  final  issue  considered  was  the  integration  of 
program  routines  with  the  graphics  program  main  event  queue. 
It  was  decided  that  controls  would  be  defined  first,  before 
entering  the  queue  loop,  in  a  window  that  would  run 
concurrently  with  the  design  easel  and  the  message  buffer. 
Routines  to  process  actions  involving  controls  would  be 
governed  by  global  boolean  variables  inside  the  event  queue 
loop.  Display  of  controls  drawn  as  a  result  of  some  user 
action  would  also  take  place  within  the  event  queue.  Figure 
3.1  illustrates  basic  program  layout. 


#define  MAIN  /*  define  MAIN  for  global  variable 

recognition  */ 

#include  "interface. h"  /*  definitions  for  variables  and 

structures  */ 

/*  main  driver  routine  */ 
main ( ) 

{ 

. . . (open  main  window) 

. . . (open  control  palette  window) 

. . . (open  message  buffer  window) 

. . . (define  controls) 
while  ( ! exitprogram) 

. . . (process  event  queue  tokens) 

. . . (redraw,  if  necessary) 

. . . (change  input  window,  if  necessary) 

. . . (process  mouse  hit,  if  necessary) 

. . . (process  routines  to  manipulate  controls) 

. . . (send  informative  messages  to  message  buffer  window) 
. . . (display  controls) 
swapbuf fers ( ) ; 

} 


Figure  3 . 1  Program  Layout  Showing  Included  Files 
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B.  DATA  STRUCTURES 


1 .  Savina  Graphics  Information 

As  noted  in  Section  A  of  this  chapter,  a  critical 
program  design  issue  involved  selection  of  a  data  structure 
that  would  hold  graphics  information  for  each  control  drawn 
in  the  design  window.  A  record  structure  is  chosen  for  this 
job,  primarily  because  of  its  ability  to  group  individual 
data  elements  of  different  data  types  as  a  single  unit. 
This  feature  of  the  record  structure  is  important  since 
controls  have  a  number  of  attributes  of  different  data 
types,  such  as  character  type  titles,  floating  point  x 
center  ctnd  y  center  coordinates,  and  integer  identification 
numbers.  The  record  structure  is  advantageous  also  because: 
(1)  it  allows  the  information  about  a  control  to  be  treated 
as  a  single  data  element,  and  (2)  it  permits  separate  use  of 
any  single  data  field  within  the  record  element  itself.  The 
ability  to  treat  a  data  structure  as  a  single  element  means 
that  records  can  be  manipulated  in  ways  which  correspond  to 
the  actual  manipulation  of  control  icons.  Deleting  a 
control  icon,  for  instance,  is  as  easy  as  eliminating  the 
record  structure  for  that  particular  icon.  The  ability  to 
address  single  data  fields  of  a  record  means  that  current 
values  and  coordinate  values  can  be  easily  updated  or 
changed. 

The  NPS  IB  program  uses  a  different  record  structure 
for  each  control  in  the  program.  This  is  necessary  since 
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different  types  of  controls  have  different  attributes.  The 
record  for  a  toggle  box  is  displayed  in  Figure  3.2.  The 
title  field  holds  the  name  of  the  toggle  box,  as  entered  by 
the  user.  The  num  field  holds  a  unique  value  which  enables 
use  of  the  IRIS  picking  mechanism  since  it  becomes  the 
loadname  of  the  control.  The  onoff  field  represents  a 
boolean  value  indicating  whether  the  toggle  box  is  turned  on 
or  off.  The  Xcoord  and  Ycoord  fields  hold  the  center  x  and 
center  y  coordinates  which  are  determined  when  the  tool  is 
positioned  in  the  design  window.  The  llxbd,  urxbd,  llybd, 
and  urybd  fields  represent  the  lower  left  x,  upper  right  x, 
lower  left  y,  and  upper  right  y  bounds  of  the  control. 
These  boundaries  are  used  to  identify  controls  in  the  design 
window  when  in  the  operate  control  mode. 


/*  define  the  structure  which  will  hold  graphics  information 

about  toggle  boxes  */ 

typedef  struct  atogboxrecord  { 

char  title[50];  /*  holds  user-input  title  */ 
int  num;  /*  unique  number  used  as  loadname  of  the 
control  */ 

int  onoff;  /*  indicates  tog  box  on  or  off  position  */ 
float  Xcoord;  /*  center  x  coordinate  of  the  control  */ 

float  Ycoord;  /*  center  y  coordinate  of  the  control  */ 

float  llxbd;  /*  lower  left  x  boundary  coordinate  */ 

/*  upper  right  x  boundary  coordinate  */ 

/*  lower  left  y  boundary  coordinate  */ 


float  urxbd; 
float  llybd; 
float  urybd; 
struct  atogboxrecord  *next; 
}  togboxrecord,  *ptogboxrecord; 


/*  upper  right  y  boundary  coordinate  */ 

/*  next  pointer  */ 


Figure  3.2  Toggle  Box  Record  Structure 
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A  dial  record  is  shown  in  Figure  3.3.  Fields  in  the 
dial  record  with  the  same  name  as  fields  in  the  toggle  box 
record  also  share  the  same  functions.  Four  additional 
fields  in  the  dial  record  require  explanation.  The  max 
field  is  used  to  save  the  user- input  maximum  value  for  the 
control,  while  the  start  field  is  used  to  record  the 
user-input  minimum  value.  The  current  field  holds  the 
current  value  of  the  dial  at  any  given  time,  and  the  theta 
field  holds  the  current  rotation  angle  of  the  dial  needle. 


/*  define  the  structure  which  will  hold  graphics  information 
about  dials  */ 

typedef  struct  adialrecord  { 

char  title [50];  /*  holds  user-input  title  */ 

int  num;  /*  unique  number  used  as  loadname  of  the 
control  */ 

float  max;  /*  holds  user-input  maximum  value  */ 
float  current;  /*  holds  control  current  value  */ 
float  start;  /*  holds  user-input  initial  value  */ 

/*  holds  current  dial  needle  rotation 
angle  */ 

/*  center  x  coordinate  of  the  control  */ 
center  y  coordinate  of  the  control  */ 
lower  left  x  boundary  coordinate  */ 
upper  right  x  boundary  coordinate  */ 
lower  left  y  boundary  coordinate  */ 
upper  right  y  boundary  coordinate  */ 

/*  next  pointer  */ 


float  theta; 


float  Xcoord; 
float  Ycoord; 
float  llxbd; 
float  urxbd; 
float  llybd; 
float  urybd; 
struct  adialrecord  *next; 
}  dialrecord,  *pdialrecord; 


/* 

/* 

/* 

/* 

/* 


Figure  3.3  Dial  Record  Structure 


The  record  for  a  vertical  slider  is  illustrated  in 
Figure  3.4.  Again,  fields  in  the  vertical  slider  record 
with  the  same  names  as  fields  in  the  dial  and  toggle  box 
records  also  share  the  same  functions.  Two  additional 
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fields  in  the  vertical  slider  record  require  explanation. 
The  min  field  holds  the  user-input  minimum  value  for  the 
slider,  and  the  position  field  holds  the  center  x  coordinate 
of  the  slider  button. 


/*  define  the  structure  which  will  hold  graphics  information 

about  vertical  sliders  */ 

typedef  struct  averticalsliderecord  { 

char  title[50];  /*  holds  user-input  title  */ 
int  num;  /*  unique  number  used  as  loadname  of  the 
control  */ 

float  max?  /*  holds  user-input  maximum  value  */ 

float  min;  /*  holds  user-input  minimum  value  */ 

float  current;  /*  holds  current  value  of  the  control  */ 


float  start;  /*  holds  user-input  initial  value  */ 
float  Xcoord;  /*  center  x  coordinate  of  the  control 

float  Ycoord;  /*  center  y  coordinate  of  the  control 

float  position;  /*  holds  current  position  of  slider 

button  */ 

lower  left  x  boundary  coordinate  */ 
upper  right  x  boundary  coordinate  */ 
lower  left  y  boundary  coordinate  */ 
upper  right  y  boundary  coordinate  */ 
struct  averticalsliderecord  *next;  /*  next  pointer  */ 
}  verticalsliderecord,  *pverticalsliderecord; 


*/ 

*/ 


float  llxbd; 
float  urxbd; 
float  llybd; 
float  urybd; 


/* 

/* 

/* 

/* 


Figure  3.4  Vertical  Slider  Record  Structure 


The  horizontal  slider  record  structure  is  an  exact 
duplicate  of  the  vertical  slider  record  and  is  not  reprinted 
here.  The  horizontal  and  vertical  slider  record  structures 
could  have  been  combined  into  one  set  of  records,  however, 
it  was  decided  that  the  program  made  more  logical  sense  if 
each  control  had  its  own  grouping  of  records. 
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2 .  The  Linked  List  Structure 


Each  control  record  structure  contains  an  additional 
field  called  next,  which  holds  a  pointer  to  another  record 
structure  of  similar  type.  Linking  the  records  together  in 
this  way  is  advantageous  for  several  reasons.  Control 
records  can  easily  be  added  to  or  deleted  from  the  linked 
list.  The  linked  list  structure  eliminates  the  need  for 
keeping  global  counters  that  would  dictate  how  many  times  to 
call  the  drawing  routine  for  a  particular  control.  The 
count  is  provided  instead  by  a  traversal  of  the  linked  list, 
which  visits  each  control  record  exactly  once.  The  linked 
list  structure  provides  control  over  the  composition  of  the 
design  window,  since  pointers  can  be  rerouted  to  eliminate 
drawing  of  selected  controls.  This  scheme  is  used  to  move 
controls  in  the  design  window.  Pointers  are  temporarily 
routed  around  the  control  to  be  moved  while  its  new 
placement  is  determined.  When  the  control  is  fixed  in 
place,  the  pointers  are  reconnected  and  the  control  is  drawn 
in  turn  when  the  list  is  traversed. 

C.  SYSTEM  STARTUP 

The  executable  program  file  is  interface.  While  in  the 
directory  containing  the  executable  file,  type  interface  to 
start  the  program.  Three  windows  open  and  run  concurrently 
during  NPS  IB  operation. 

The  design  window  opens  to  full  screen  size,  but  can  be 
immediately  resized  if  the  user  desires.  The  control 
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palette  window  opens  in  the  upper  right  hand  corner  of  the 
screen  and  draws  its  inventory  of  controls.  The  message 
buffer  window  opens  in  the  lower  left  hand  corner  of  the 
screen  and  displays  opening  messages  and  advice.  The 
locations  of  both  the  control  palette  and  message  buffer 
windows  can  be  moved  to  different  positions  if  the  user  so 
desires . 

The  user  must  select  an  option  from  the  system  menu  in 
order  to  operate  the  program.  The  system  menu  is  shown  in 
Figure  3.5.  The  system  menu  is  a  popup  menu  with 
roll-of f-the-side  options,  and  is  invoked  by  depressing  the 
right  mouse  button.  Releasing  the  right  mouse  button  on  the 
menu  selection  desired  prompts  the  system  to  execute  the 
action  for  that  selection.  The  user  can  select  any  menu 
option  at  any  time  during  program  execution.  If  the  user 
chooses  a  menu  option  that  is  not  meaningful,  however,  no 
action  is  taken.  The  save  design  option  chosen  at  this 
point  writes  only  the  lower  left  x  and  y  coordinates  and  the 
upper  right  x  and  y  coordinates  of  the  design  window  to  its 
output  files. 

D.  MAIN  DRIVER  ROUTINE 

The  NPS  IB  main  driver  routine  is  located  in  the  file 
interface. c.  The  main  driver  routine  directs  program  action 
based  on  user  menu  selection.  Evaluation  of  user  menu 
selection  is  made  in  the  routine  handletoken,  located  in  the 
file  handletoken. c.  The  routine  handletoken  switches  on  the 
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Figure  3.5  NPS  Interface  Builder  System  Menu 


value  of  the  menu  selection,  sets  appropriate  global  boolean 
variables  based  on  the  user  menu  selection,  sends 
appropriate  messages  to  the  message  buffer  window,  and 
returns  to  the  main  routine.  As  the  main  routine  cycles 
through  the  event  loop,  if-loop  constructs  governed  by  the 
global  boolean  variables  are  evaluated.  On  evaluation  of  a 
true  boolean  variable,  the  if-loop  is  entered  and  routines 
performing  the  action  corresponding  to  the  user  menu 
selection  are  executed.  A  switch  statement  might  have  been 
used  here  with  equal  effectiveness. 
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Each  cycle  through  the  event  loop  also  draws  the  three 
concurrently  running  windows.  This  is  to  ensure  that  the 
keyboard  input  window,  which  pops  up  when  user  input  is 
required  and  closes  when  user  input  is  complete,  is  fully 
erased  from  any  of  the  window  which  it  might  overlay. 

The  majority  of  constant  and  global  variable  definitions 
are  located  in  the  include  file  interface. h.  Control  record 
structures  are  also  defined  in  this  file.  Global  variables 
defined  in  interface. h  include  those  which  govern  program 
action  and  which  establish  size  for  control  icon  drawing.  A 
small  number  of  global  constant  definitions  are  located  in 
the  include  file  sbglobal.h.  The  original  version  of  this 
file  belongs  to  the  S  &  B  package,  which  was  described  in 
Chapter  I.  The  sbglobal.h  file  became  part  of  the  NPS  IB 
program  because  original  plans  for  the  program  called  for 
integration  of  the  S  &  B  package  as  a  feature  that  would 
quickly  create  button  and  slider  windows,  however,  this 
feature  of  the  NPS  IB  program  was  never  fully  implemented. 
Although  this  feature  of  the  program  was  never  realized,  the 
sbglobal.h  file,  with  a  few  modifications,  remains  a  part  of 
the  NPS  IB.  The  sbglobal.h  file  contains  constant 
definitions  for  color  and  size  of  program  icon  drawings. 

E.  REDRAW/RESIZE  CODE 

When  the  NPS  IB  program  executes,  the  design  window 
opens  to  full  screen  size.  In  the  original  program  design, 
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the  full  screen  design  window  was  the  only  size  design 
window  offered.  This  was  considered  too  constraining  for  a 
user,  however,  who  might  have  need  for  a  variety  of  sizes  of 
control  windows.  It  was  decided  to  offer  the  user  an  option 
to  resize  the  design  window,  and  to  enable  the  user  to  move 
the  control  palette  and  message  buffer  windows  to  new 
positions  as  well. 

The  user  can  select  the  resize  or  move  option  by  using 
the  right  mouse  button  to  pull  down  the  menu  from  the  title 
bar  of  the  window  in  question.  This  pull  down  menu  is  not  a 
product  of  the  NPS  IB  program,  but  rather  is  a  creation  of 
the  window  manager.  The  selection  of  a  resize  or  move  menu 
option  generates  a  program  REDRAW  token  which  must  then  be 
processed  by  the  main  event  queue.  The  NPS  IB  program 
contains  code  which  will  relocate  and  redraw  windows  when 
the  REDRAW  token  is  received.  This  code  is  drawn  from  the 
S  &  B  package  program. 

When  the  resize  option  is  indicated  for  the  design 
window,  the  user  manipulates  the  mouse  to  interactively 
sweep  out  a  new  size  for  the  window.  The  click  of  any  mouse 
button  drops  the  newly  sized  window  into  place.  Resize  code 
for  the  design  window  records  the  new  window  coordinates  and 
uses  them  to  compute  new  x  and  y  ratios  of  world  to  screen 
coordinates.  The  new  ratio  values  in  turn  are  used  to 
recalculate  global  variables  for  drawing  controls.  This 
code  is  illustrated  in  Figure  3.6.  Recalculating  the  global 
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/•  this  routine  calculates  global  coordinates  for  tool  drawing  •/ 
a«t global coordinates (lldx,lldy,urdx,  urdy ) 
int  lldx, lldy , urdx, urdy : 
l 

aet_acal«X  -  120 . 0.'  (  (float )  (urdx*  -  (float  Mlldx)  )  ; 
aet_tcaleY  “  100 . 0/ ( (float ) (urdy >- (float Mlldy) ) ; 

/•  determine  width  of  tog  button  •/ 
togbuttonwidth  •  BU 1  lOHWlPTH  •  aet_»celeX; 
togbuttonwidth2  -  togbuttonwidth/2 ; 

/•  determine  height  of  tog  button  •/ 
togbut  tonHT  -  BPTTOHHT  •  set_scaleY; 
t ogbuttonHT2  •  togbuttonHT  /  2; 

/•  determine  outline  parameters  of  tog  button  •/ 
togbuttor._out lineX  -  BUTTOMOUTLIKEWidth  *  set_scalex: 
t ogbut t on_out  1  me Y  -  BOTTOHOITLINEMIDTH  •  set_*caleY; 

/•  deterrrane  width  of  dial  box  •/ 
dialwidth  •  DIALWIDTH  •  set_scaleX; 
dialwidth2  -  dialwidth, 2; 

/•  determine  height  of  dial  box  •/ 
dialHT  »  DlALHT  •  set_ecaleY; 
dialHTl  •  dialHT/2; 

/•  determine  dial  outline  parameters  * 
dialout 1 ineX  -  DIALOtTLI WEWIDTH  *  »et_scaleX; 
dialout lineY  -  DIALOITTLINEWIDTH  •  eet~sc«leY ; 

/•  determine  dial  radius  • 

insideradius  •  dialwidth!  -  dialoutlineX  -  0.3; 
outradius  -  dialwidth!  -  dialoutlineX  -  0.1; 

/•  determine  width  of  vertical  slider  bar  •/ 
vertbarwidth  •  BARWIDTH  •  set_scaleX; 
vertbarwidth!  •  vertbarwidth  2; 

/•  determine  height  of  vertical  slider  bar  • 
vertbarHT  •  BAJtHT  •  *et_scaleY; 
vertbarHT!  -  vertbarHT  .  2; 

/•  determine  width  cf  slider  button  • / 
vert slide rwidt h  -  SLIDEPWIDTH  *  set_scaleX; 
vertsiiderwidthl  •  vert siiderwidth .2.; 

/•  deterrrane  height  cf  slider  butter.  • 
vert sliderHT  -  SLIDERWIDTh  •  set_sceleY , 2 ; 

▼ertsiiderHT2  -  vertsliderHT  2; 

/•  determine  width  of  slider  bar  inside  • 

vert msidebarwidth  •  InsideBAFWlDTh  •  set_scaieX: 

vertinsidebarwidthl  -  vert insidetarw- dt h  !; 

/•  deterrrane  width  of  horizontal  slider  bar  • 
hrbarwidth  -  BAKU!  •  aet_scaleX; 
hrbarwidth*  ■  hrbarwidth  2; 

/•  determine  height  of  hcnrontal  slider  bar  • 
hzbarHT  -  BAAWIDTH  •  »et_scaleY; 
hrbarHT!  -  hzbarHT/ 2; 

/•  determine  width  of  alider  button 
hrsliderwidt h  »  SLIDERWJdtm  •  aet_#calex,  2 ; 
hzsliderwidt h2  »  hrsliderwidt h/2 ; 

/•  determine  height  of  slider  button  •/ 
hrsliderHT  -  3LXDERWIDTH  *  set_sealeY. 
hrsliderHT2  -  hzsliderHT/2 ; 

/•  determine  width  of  alider  bar  inside  •/ 
hrinaidebarwidth  -  XnsldeBARWIDTM  *  eet_ecaleY; 
hrinsidebarwidth2  •  hnnsidebarwidt h  '2 ; 


Figure  3.6  Code  to  Set  Global  Coordinates  for 
Drawing  control  Icons 
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variables  based  on  new  x  and  y  ratios  is  necessary  to 
prevent  distortion  of  icon  drawings  in  the  resized  design 
window. 

Drawing  of  controls  in  the  main  window  is  accomplished 
in  the  world  coordinate  system.  This  was  done  to  facilitate 
integration  of  NPS  IB  with  the  S  &  B  package  program,  which 
draws  sliders  and  buttons  in  world  coordinate  system 
coordinates.  Although  the  S  &  B  package  program  was  never 
fully  integrated  with  NPS  IB,  the  world  coordinate  system 
remained  the  basis  for  NPS  IB  control  drawings. 
Unfortunately,  using  the  world  coordinate  system  means  that 
some  distortion  of  the  dial  icon  may  occur  if  the  design 
window  swept  out  by  the  user  does  not  approximate  a  square. 
This  occurs  because  world  coordinates  may  be  stretched 
longer  along  one  axis  of  the  design  window  if  the  window 
does  not  approximate  a  square.  This  has  the  effect  of 
stretching  the  dial  circle  in  the  direction  of  the  long 
axis,  making  it  look  more  oval  than  circular.  This  problem 
can  be  resolved  by  adjusting  the  world  coordinate  system  to 
compensate  for  the  longer  window  axis. 

Resize  and  redraw  code  works  the  same  way  for  the 
control  palette  window  as  for  the  design  window.  New  window 
coordinates  are  obtained,  ratios  calculated,  global 
variables  computed,  and  the  window  is  redrawn.  Redraw  code 
for  the  message  buffer  is  much  simpler,  however,  since  this 
window  always  remains  the  same  size.  To  effect  a  move  of 
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the  message  buffer  window,  it  is  necessary  to  obtain  the 
lower  left  x  and  lower  left  y  coordinates  of  the  new  window 
position  and  enter  them  into  the  window  record  structure. 
The  message  buffer  window  is  then  drawn  in  its  new  position. 

F .  DRAWING  ALGORITHMS 

1 .  Control  Palette  Window  Drawings 

Four  controls  are  drawn  in  the  control  palette 
window  after  the  main  routine  opens  the  window  up.  These 
four  controls  are  a  toggle  box,  a  dial,  and  two  versions  of 
a  slider,  one  oriented  lengthwise  along  the  y  axis  and  the 
other  oriented  lengthwise  along  the  x  axis. 

Code  for  drawing  the  control  palette  window  is 
located  in  the  file  toolwindow.c.  First,  global  variables 
for  drawing  control  icons  are  calculated  based  on  world  to 
screen  ratios  as  described  in  the  previous  section  of  this 
chapter.  Then  the  center  x  and  center  y  of  each  control  are 
established.  The  control  center  x  and  center  y  are  fixed 
points  specified  in  the  global  include  file  tglobal.h.  This 
means  that  positions  of  controls  in  the  window  can  be 
altered  by  editing  the  tglobal.h  file  rather  than  by 
accessing  the  drawing  code  directly.  A  single  pass  through 
the  drawtools  routine  then  draws  each  control  icon.  For 
each  rectangular  portion  of  each  control  drawn,  the  lower 
left  corner  and  upper  right  corner  points  are  calculated, 
utilizing  center  points  and  global  size  variables.  Text 
drawing  is  accomplished  in  the  same  way.  For  circle 
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drawing,  the  center  x  and  y  points  are  given  in  tglobal.h 
and  the  radius  is  calculated  based  on  the  size  of  the  dial 
outline  box.  A  control  identification  number  is  loaded  onto 
the  names  stack  as  the  largest  portion  of  each  control  is 
drawn.  This  number  identifies  the  type  of  control  for  the 
IRIS  picking  mechanism. 

2 .  Design  Window  Drawing 

Code  for  drawing  control  icons  in  the  design  window 
is  located  in  the  file  draw.c.  The  code  in  the  file  handles 
two  cases  of  drawing  controls  in  the  design  window.  The 
first  case  involves  the  drawing  of  a  floating  control  tied 
to  the  mouse  cursor,  which  the  user  can  then  move  about  the 
design  window  to  determine  control  placement.  The  second 
case  involves  drawing  a  fixed  control  which  appears  in  the 
design  window  after  the  user  clicks  the  middle  mouse  button 
to  set  placement  of  the  floating  control. 

Four  separate  routines  accomplish  the  drawing  of  the 
four  controls.  The  separation  of  control  drawing  routines 
permits  the  use  of  the  same  drawing  code  for  drawing  of  both 
floating  and  fixed  controls.  Figure  3.7  shows  the  code  used 
to  select  the  appropriate  drawing  routine  for  the  floating 
control  icon.  The  routine  switches  on  the  variable  tool- 
picked,  which  holds  the  identification  number  of  the  type  of 
control  selected  from  the  control  palette  window.  The  case 
statement  is  entered  when  toolpicked  matches  a  control 
identification  number,  and  subsequently  the  appropriate 
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/*  this  routine  determines  which  floating  tool  is  to  be 
drawn  */ 

drawthefloatingtool ( fx, fy) 
float  fx,fy; 

{ 

switch (toolpicked) 

{ 

case  TOGBOX: 

/*  draw  a  toggle  box  */ 
drawfloatl  =  TRUE; 
drawthetogbox ( fx, fy , titlebuf f er) ; 

break; 

case  DIAL: 

/*  draw  a  dial  */ 

drawfloat2  =  TRUE; 

drawdial ( fx, fy, titlebuf fer, curnum) ; 

break ; 

case  VSLIDER: 

/*  draw  a  vertical  slider  */ 
drawfloat3  =  TRUE; 

drawvertsl ider ( f x , f y , si idert it le , curnum) ; 
break; 

case  HSLIDER : 

/*  draw  a  horizontal  slider  */ 
drawfloat4  =  TRUE; 

drawhorizslider (fx, fy, slidertitle, curnum) ; 
break; 
default: 

qdevice (INPUTCHANGE) ; 
qdevice (RIGHTMOUSE) ; 
qdevice (LEFTMOUSE) ; 

break ; 

} 

} 


Figure  3.7  Program  Code  for  Drawing  Floating  Control 
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control  drawing  routine  is  called.  Because  the  same  code  is 
used  for  drawing  floating  and  fixed  controls,  it  became 
necessary  to  number  the  drawfloat  variable  in  order  to 
prevent  side  effects  to  the  other  controls  when  any  floating 
control  was  being  drawn.  By  numbering  the  drawfloat 
variable,  it  was  possible  to  draw  just  a  floating  dial,  for 
example,  and  still  cycle  through  the  drawing  code  for  the 
other  controls  without  any  adverse  affects,  even  though  that 
code  also  contained  provisions  for  drawing  floating 
controls.  Figure  3.8  illustrates  the  code  used  to  draw 
fixed  controls  in  place  in  the  design  window.  After  a 
control  is  selected  from  the  control  palette  and  dropped 
into  place  in  the  design  window,  a  record  structure  is 
created  for  the  control  and  entered  into  the  control  linked 
list.  This  reduces  the  drawing  algorithm  to  a  traversal  of 
four  linked  lists,  with  the  proper  drawing  routine  called 
for  each  control  encountered  in  the  traversal.  As  each 
control  in  the  list  is  traversed,  pointers  access  the 
information  for  that  control  and  provide  the  information  to 
the  drawing  routine. 

Each  control  drawing  routine  is  configured  to  handle 
the  drawing  of  a  floating  or  fixed  control.  The  routine  for 
drawing  a  toggle  box  is  shown  in  Figure  3.9  as  an  example. 
If  a  floating  control  is  to  be  drawn,  the  routine  is  entered 
with  the  x  and  y  coordinates  of  the  cursor,  which  at  this 
point  has  been  placed  in  the  center  of  the  design  window. 
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/*  this  routine  draws  the  design  window  picture  by  calling 
individual  tool 
drawing  routines  */ 
drawthepicture ( ) 

{ 

/*  for  the  number  of  toggle  boxes  we  have  ...  */ 
for  (togboxcurrent  =  togboxhead;  togboxcurrent  !=  NULL; 
togboxcurrent  =  togboxcurrent->next) 

/*  ...  draw  them  */ 

drawthetogbox ( togboxcurrent->Xcoord , togboxcurrent->Ycoord , 
togboxcurrent->title) ; 

/*  for  the  number  of  dials  we  have  ...  */ 
for  (dialcurrent  =  dialhead;  dialcurrent  !=  NULL; 
dialcurrent  =  dialcurrent->next) 

/*  ...  draw  them  */ 

drawdial (dialcurrent->Xcoord , dialcurrent->Ycoord , dialcur- 
rent->title,  dialcurrent->current) ; 

/*  for  the  number  of  vertical  sliders  we  have  ...  */ 
for  (verticalslidercurrent  =  verticalsliderhead; 
verticalslidercurrent  !=  NULL;  verticalslidercurrent  = 
vert ical si idercurrent->next ) 

/*  ...  draw  them  */ 

drawvertslider (verticalslidercurrent->Xcoord, 
vert icalsl idercurrent->Ycoord, vert icalsl idercurrent->t it le, 
verticalslidercurrent->  current) ; 

/*  for  the  number  of  horizontal  sliders  we  have  ...  */ 
for  (horizslidercurrent  =  horizsliderhead; 
horizslidercurrent  !=  NULL;  horizslidercurrent  = 
horizslidercurrent  ->next) 

/*  ...  draw  them  */ 

drawhorizslider (horizslidercurrent->Xcoord, 
horizslidercurrent->  Ycoord,horizslidercurrent->  title, 
horizslidercurrent->  current) ; 

}  /*  end  drawthepicture  */ 


Figure  3.8  Program  Code  for  Drawing  Fixed  Controls 
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/•  this  routine  draws  the  checkboxes  in  the  main  window  •/ 
drawthetogbox (tx, ty, string) 
char  "string; 
float  tx,ty; 

( 

float  xl,x2,yl,y2; 

/•  save  the  matrix  on  top  of  the  stack  */ 
pushmatrix  () ; 

if  (drawfloatl) 

( 

/*  translate  the  tool  to  where  we  want  it  */ 
translate (tx, ty, 0.0); 

/*  need  to  draw  the  tool  at  0.0  so  it  may  be  properly  translated 
tx  -  0.0; 
t  y  ™  C  .  0 ; 

) 

/•  draw  the  button  outline  */ 
xl  -  tx  -  togfcuttonwxdth2; 

x2  •  xl  4  togbuttonwidth; 

yl  -  ty  -  togbuttonHT2 ; 

y2  »  yl  +  togbuttonHT; 

RGBcolor (BUTTONOUTLINE)  ; 
if  (Idrawfloat) 

loadname (togboxcurrent ->num) ; 
rectf (xl, yl, x2, y2) ; 

/•  draw  the  button  inside  •/ 
xl  -  xl  4  togbutton_out lineX ; 

x2  -  x2  -  togbutton_out lineX; 

yl  -  yl  4  togbuttcn_outlineY; 

yl  -  y2  -  t og^ut ton_out lineY ; 

if  (drawfloatl) 

{ 

RGBcolor (BV7T0NINSIDE0FF) ; 
rectf (xl , yl , x2, y2> ; 

I 

else 

I 

if  (togboxcurrent->onof f  ON) 

( 

RGBcolor (BUTTON INS IDEON) ; 
rectf (xl , yl , x2, y2)  ; 

) 

else 

( 

RGBcolor (BUTTONINSIDEOFF) ; 
rectf (xl , yl , x2, y2) ; 

) 

) 

/*  draw  the  button  title  •/ 

RGBcolor (T1TLECOLOP) ; 

xl  •  tx  4  25  *  set_scaleX; 

yl  -  ty  -  togbuttonHT2  *  set_scaleY; 

cmov2  (xl ,  yl )  ; 

charstr (string)  ; 

/•  restore  the  top  of  the  matrix  stack  */ 
popcaatrxx  ()  ; 

drawfloatl  •  FALSE ; 


Figure  3.9 


Toggle  Box 


Drawing  Routine 
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The  drawing  matrix  is  saved  on  top  of  the  stack,  and  the 
routine  if-loop  construct  is  entered.  In  the  if-loop 
construct,  the  computer  is  instructed  to  translate  the 
drawing  of  the  control  to  the  position  of  the  cursor.  This 
ties  the  drawing  of  the  control  to  the  position  of  the 
cursor  and  creates  the  floating  effect  of  the  control.  The 
x  and  y  coordinates  passed  into  the  routine  are  then  set  to 
zero,  and  become  the  center  x  and  center  y  for  drawing  of 
the  control.  This  means  that  the  icon  is  drawn  at 
(0.0, 0.0, 0.0)  and  then  translated  to  the  position  of  the 
cursor.  The  top  of  the  matrix  stack  is  then  popped. 

If  a  fixed  control  is  to  be  drawn,  the  drawing 
routine  is  entered  with  the  control  record  x  and  y 
coordinates,  which  were  saved  when  the  user  dropped  the 
floating  control  into  the  design  window.  The  if-loop 

construct  of  the  routine  is  skipped,  eliminating  the 
translation  portion  of  the  routine.  The  saved  x  and  y 

coordinates  are  then  used  to  calculate  coordinates  for 
control  drawing.  In  addition,  a  unique  identification 

number  is  loaded  with  the  largest  portion  of  the  fixed 

control  drawn.  This  number  is  used  to  identify  the  control 
for  the  IRIS  pick  mechanism. 

G.  EDIT  DESIGN  MODE 

1.  IRIS  Picking  Mode 

The  IRIS  picking  mechanism  can  be  used  to  identify 
objects  on  the  screen  that  appear  near  the  cursor.  When  the 
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picking  mechanism  is  invoked,  the  system  loads  the  product 
of  the  window  projection  transformation  matrix  and  the 
picking  matrix  at  the  top  of  the  matrix  stack.  This  maps 
objects  to  be  picked  to  their  proper  coordinates.  The 
system  then  records  hits  for  any  routines  that  draw  into  the 
picking  region  [Ref.  9]. 

2 .  Control  Selection 

The  IRIS  picking  mechanism  is  used  to  select 
controls  in  the  control  palette  window.  When  a  control  is 
picked,  its  identification  number  is  loaded  into  the 
variable  toolpicked.  The  user  is  then  asked  to  give  the 
control  name  and  value  attributes.  The  code  to  perform 
this  action  is  located  in  the  file  process. c.  The  nametool- 
picked  routine  switches  on  the  value  of  toolpicked  in  order 
to  make  proper  gueries  to  the  user  for  obtaining  control 
information.  The  nametoolpicked  routine  calls  the  keyboard 
input  routine  in  order  to  permit  users  to  enter  information. 
When  proper  information  for  the  control  has  been  obtained, 
the  system  draws  a  floating  control  as  described  in  Section 
F  of  this  chapter. 

3 .  Creating  Record  Structures  for  Savina  Graphics 

Information 

When  the  user  clicks  the  middle  mouse  button  to  drop 
a  control  into  the  design  window,  a  record  structure  is 
allocated  for  the  control,  and  all  graphics  information  is 
immediately  recorded  into  the  proper  field.  The  code  for 
accomplishing  this  is  also  located  in  the  file  process. c. 
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Figure  3 . 10  shows  creation  of  a  record  structure  and  saving 
of  graphics  information  for  a  toggle  box.  The  code 
illustrated  also  shows  the  insertion  of  the  record  into  the 
linked  list.  If  it  is  the  first  record  in  the  list,  the 
head  and  tail  pointers  are  set  to  that  record  and  the  next 
pointer  is  set  to  NULL.  If  the  record  is  not  first  in  the 
list,  the  record  is  just  appended  to  the  list  and  the  tail 
pointer  is  adjusted  to  that  record.  This  process  works  the 
same  way  for  the  other  controls,  thus  code  for  those 
operations  is  not  reprinted  here. 

H.  MOVE  CONTROL  MECHANISM 

The  NPS  IB  program  would  be  terribly  constraining  if 
users  were  locked  in  to  any  one  placement  for  a  control. 
The  move  control  mechanism  gives  a  user  the  ability  to  move 
controls  that  have  already  been  placed  in  the  design  window. 
The  routines  that  provide  NPS  IB  with  its  move  capability 
are  located  in  the  file  move.c.  In  addition,  move.c 
contains  the  routine  which  will  delete  a  control  from  the 
design  window. 

The  IRIS  picking  mechanism  is  used  to  select  the  control 
to  be  moved  in  the  design  window.  The  identification  number 
of  the  control  selected  is  read  into  the  variable  tool- 
picked.  The  routine  getcontrolid  searches  through  record 
structures  in  each  linked  list,  attempting  to  match  the 
number  in  the  variable  toolpicked  with  the  identification 
number  saved  in  each  record  structure.  Figure  3.11  shows  a 
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/*  allocate  memory  for  this  guy  */ 

cbr  =  (togboxrecord*)malloc(sizeof (togboxrecord) ) ; 

/*  store  the  graphics  information  */ 
strcpy (cbr->title, titlebuf fer) ; 
cbr->num  =  control index; 
cbr->Xcoord  =  sx; 
cbr->Ycoord  =  sy; 

cbr->llxbd  =  sx  -  togbuttonwidth2 ; 

cbr->urxbd  =  (sx  -  togbuttonwidth2 )  +  togbuttonwidth ; 

cbr->llybd  =  sy  -  togbuttonHT2 ; 

cbr->urybd  =  (sy  -  togbuttonHT2 )  +  togbuttonHT; 

cbr->onoff  =  OFF; 

cbr->next  =  NULL; 

/*  put  the  guy  in  the  list  */ 
if  (togboxhead  ==  NULL) 

{ 

/*  this  is  the  first  guy  in  the  list  */ 
togboxhead  =  togboxtail  =  cbr; 

/*  set  tail  pointer  to  null  */ 
togboxtail->next  =  NULL; 

} 

else 

( 

/*  set  the  pointer  for  the  last  guy  in  the  list  to  the  new 
guy  */ 

togboxtail->next  =  cbr; 

/*  now  reset  the  tail  pointer  */ 
togboxtail  =  cbr; 

} 


Figure  3.10  Record  Creation  and  List  Maintenance 
for  a  Toggle  Box 


code  segment  from  the  routine  used  to  accomplish  this.  If 
the  control  is  found,  the  identification  number  in  the 
variable  toolpicked  is  replaced  by  a  second  number 
identifying  the  type  of  control  found.  This  is  because  the 
variable  toolpicked  will  be  used  to  determine  the  type  of 
floating  control  icon  to  be  drawn  in  the  design  window  when 
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/*  this  routine  identifies  the  tool  found  in  the  pick  */ 
getcontrolid() 

{ 

int  found  =  FALSE; 

/*  set  previous  and  current  list  pointers  to  head  */ 
togboxprevious  =  togboxcurrent  =  togboxhead; 
verticalsliderprevious  =  verticalslidercurrent  = 
verticalsliderhead; 

horizsliderprevious  =  horizslidercurrent  = 
horizsliderhead ; 

dialprevious  =  dialcurrent  =  dialhead; 

/*  loop  through  all  the  lists  until  we  find  the  guy  ...  */ 
while  ((Ifound)  &&  (toolpicked  >  0)) 

{ 

/*  search  the  list  of  toggle  boxes  */ 
while  ((togboxcurrent  !=  NULL)  &&  (Ifound)) 

{ 

if  (togboxcurrent->num  ==  toolpicked) 

{ 

toolpicked  =  TOGBOX; 

strcpy (titlebuf fer , togboxcurrent->title) ? 
if  (togboxcurrent  ==  togboxhead) 
togboxhead  =  togboxhead->next ; 
togboxtemp  =  togboxcurrent; 
found  =  TRUE; 

} 

else 

{ 

togboxprevious  =  togboxcurrent; 
togboxcurrent  =  togboxcurrent->next ; 

} 

} 

. . . (search  remaining  list  of  controls) 

}  /*  end  while  */ 

}  /*  end  getcontrolid  */ 


Figure  3.11  Searching  Linked  Lists  for  a  Control 


the  move  is  to  occur.  Any  graphics  information  necessary 
for  drawing  the  floating  control  is  transferred  from  the 
record  to  buffer  variables. 

If  the  control  to  be  moved  has  a  record  structure  at  the 
head  of  a  linked  list,  the  head  pointer  is  advanced  to  the 
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next  record  in  the  list.  This  has  the  effect  of  removing 
the  icon  drawing  from  the  design  window,  since  the  control 
drawing  algorithm  is  regulated  by  a  traversal  of  the  linked 
list,  starting  from  the  head  pointer.  If  the  control  is  not 
at  the  head  of  a  list,  the  pointer  from  the  structure 
preceding  the  control  to  be  moved  is  simply  redirected  to 
point  at  the  structure  following  the  control  to  be  moved. 
This  has  the  effect  of  erasing  the  control  from  the  design 
window  since  the  node  of  the  control  to  be  moved  is  not 
visited  when  the  linked  list  is  traversed  for  drawing. 

Erasure  of  the  control  to  be  moved  corresponds  with  the 
appearance  of  a  floating  control  in  the  design  window.  The 
floating  control  is  labeled  with  all  the  attributes  of  the 
previously  fixed  control.  The  user  manipulates  the  floating 
control  to  a  new  position,  then  presses  the  middle  mouse 
button  to  drop  the  moved  control  into  place.  Drawing  the 
moved  control  is  simply  a  matter  of  saving  the  new  graphics 
information  and  then  replacing  or  reconnecting  pointers,  as 
illustrated  in  the  code  segment  of  Figure  3.12.  If  the  head 
pointer  was  moved,  it  is  replaced  at  the  head  of  the  list. 
Otherwise,  the  pointer  preceding  the  structure  for  the  moved 
control  is  reconnected  to  the  moved  control  structure.  The 
delete  control  mechanism  is  an  extension  of  the  move  control 
mechanism.  Pointers  are  redirected  in  the  same  manner  as 
for  the  move  control  mechanism.  But  instead  of  reconnecting 
the  record  structure  when  the  middle  mouse  is  clicked,  the 
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/*  get  the  new  control  coordinates  */ 
togboxtemp->Xcoord  =  sx; 
togboxtemp->Ycoord  =  sy; 

togboxtemp->llxbd  =  sx  -  togbuttonwidth2 ; 

togboxtemp->urxbd  =  (sx  -  togbuttonwidth2)  +  togbuttonwidth; 
togboxtemp->llybd  =  sy  -  togbuttonHT2 ; 

togboxtemp->urybd  =  (sy  -  togbuttonHT2 )  +  togbuttonHT; 

/*  if  the  control  moved  had  the  head  pointer,  restore  it  */ 
if  (togboxprevious->next  ==  togboxhead) 
togboxhead  =  togboxprevious ; 
else 

togboxprevious->next  =  togboxtemp; 


Figure  3.12  Code  for  Reconnecting  a  Moved  Control 
Structure  in  the  Linked  List 


pointers  remain  in  the  new  configuration.  The  tool  is 
erased  from  the  design  window  and  is  not  replaced.  The 
memory  occupied  by  the  old  record  structure  is  freed  and 
made  available  for  other  use. 


I.  RUN  CONTROL  MECHANISM 

The  run  control  mechanism  provides  a  user  with  the 
ability  to  check  the  operation  of  controls  in  the  design 
window.  To  invoke  the  run  control  mode,  the  user  selects 
the  run  controls  option  from  the  program  main  menu.  The 
user  can  then  use  the  left  mouse  button  to  operate  any 
control  in  the  design  window.  The  run  control  option  is 
deselected  when  another  menu  option  is  chosen.  The  code  for 
the  run  control  option  is  located  in  the  file  run.c. 

When  the  run  control  mode  is  invoked,  the  mouse  x  and 
mouse  y  coordinates  are  read.  The  operatecontrol  routine 
then  traverses  the  four  linked  lists  and  compares  the  mouse 
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x  and  mouse  y  locations  with  the  boundary  limits  for  each 
control.  If  the  cursor  lies  within  the  boundary  limits  of  a 
control,  that  particular  control  is  operated.  Figure  3.13 
is  a  code  segment  illustrating  operation  of  a  toggle  box. 


/*  get  the  world  coordinates  from  the  mouse  */ 

wx  =  ( (float) (getvaluator (MOUSEX) ) -dllx) *set_scaleX; 

wy  =  ( (float) (getvaluator (MOUSEY) ) -dlly) *set_scaleY; 

/*  now  traverse  the  linked  lists  to  see  if  we  are  in  within 
the  bounding  box  of  a  control  */ 

/*  for  the  number  of  toggle  boxes  we  have  .  .  .  */ 
for  (togboxcurrent  =  togboxhead;  togboxcurrent  !=  NULL; 
togboxcurrent  =  togboxcurrent->next) 

{ 

/*  do  the  boundary  test  */ 

if  ( (wx  >  togboxcurrent->llxbd)  &&  (wx  <  togboxcurrent-> 
urxbd)  && 

(wy  >  togboxcurrent~>llybd)  &&  (wy  <  togboxcurrent-> 
urybd) ) 

{ 

/*  switch  the  control  to  the  other  position,  based  on 
what  position  its  already  in  */ 
if  (togboxcurrent->onoff  ==  OFF) 
togboxcurrent->onof f  =  ON; 
else 

togboxcurrent->onof f  =  OFF; 

} 


Figure  3.13  List  Traversal  and  Toggle  Box  Operation 
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IV.  NPS  INTERFACE  BUILDER  MESSAGE  BUFFER 


A.  PURPOSE  OF  THE  MESSAGE  BUFFER 

The  NPS  IB  message  buffer  window  gives  the  program  its 
help  capability.  The  message  buffer  window  provides  help  by 
displaying  instructions  designed  to  guide  a  user  through 
accomplishment  of  a  task  made  by  menu  selection.  The 
message  window  also  provides  verification  information  by 
sending  a  message  to  the  screen  when  some  action  has  been 
completed,  such  as  moving  or  deleting  a  control.  The 
message  buffer  window  gives  the  NPS  IB  a  means  of  providing 
more  informative  feedback  to  the  user. 

B.  OPERATION  OF  MESSAGE  BUFFER  WINDOW 

Definitions  of  structures  that  support  operation  of  the 
message  buffer  are  located  in  the  file  mess.h.  The 
structure  which  defines  a  line  of  text  to  be  displayed  in 
the  buffer  is  illustrated  in  Figure  4.1.  The  structure 
consists  of  two  pointers?  the  pointer  called  ptr  is  directed 
to  a  string  of  text  which  constitutes  a  line,  and  the 
pointer  called  next  is  directed  to  the  next  line  in  the 
buffer.  The  structure  which  holds  attributes  of  the  message 
buffer  window  is  shown  in  Figure  4.2.  The  variables  nlines 
and  nchars  hold  the  number  of  lines  in  the  buffer  and  the 
maximum  line  length  for  the  buffer  respectively.  These 
values  will  be  used  to  compute  height  and  width  for  setting 


/*  define  a  type  and  structure  for  each  line  of  the  ring 
buffer  that  is  the  message  buffer  display. 

*/ 

struct  lineinbuf 

{ 

char  *ptr;  /*  ptr  to  the  string  for  this  line  */ 

struct  lineinbuf  *next;  /*  ptr  to  next  line  in  the 

buffer  */ 

}; 

typedef  struct  lineinbuf  LINEINBUF;  /*  define  a  line  in 

the  buffer  type  */ 

Figure  4.1  Structure  that  Defines  a  Line  of  Text 

the  size  of  the  message  buffer  window.  The  pointers  topline 
and  lastline  point  to  lines  of  display  buffer  text,  with 
topline  directed  at  the  first  line  of  the  display  and 
lastline  directed  at  the  last  line  of  the  display.  The 
field  winname  holds  the  name  of  the  window  opened  for  the 
message  buffer,  and  the  fields  x  and  y  hold  the  lower  left 
corner  value  of  the  window.  Textcolor  defines  the  color  of 
the  message  buffer  text,  while  backcolor  holds  the  color  of 
the  background  of  the  message  buffer  window.  Finally,  the 
fields  width  and  height  hold  the  computed  values  of  width 
and  height  for  the  window. 

The  routines  which  create  and  operate  the  message  buffer 
window  are  located  in  the  file  mess.c.  These  routines  open 
the  message  buffer  window  and  govern  the  operation  of  the 
ring  buffer.  The  ring  buffer  provides  the  mechanism  that 
gives  the  message  buffer  window  its  appearance  of  scrolling 
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/*  define  a  type  and  structure  for  the  message  buffer  */ 
struct  messbuf 
{ 

long  nlines;  /*  number  of  lines  in  the  buffer  */ 

long  nchars;  /*  maximum  line  length  for  the  buffer  */ 

LINEINBUF  *topline;  /*  ptr  to  top  line  of  the  display 

*/ 

LINEINBUF  *lastline;  /*  ptr  to  last  line  of  the  display 

*/ 

long  winname;  /*  the  name  of  the  window  opened  for 

this  message  buffer. 

*/ 

long  x,y;  /*  lowerleft  corner  of  ther  message 

buffer  */ 

short  textcolor;  /*  color  of  the  text  in  the  message 

buffer  */ 

short  backcolor;  /*  color  of  the  background  in  the 

message  buffer  */ 

long  width;  /*  width  in  pixels  of  the  message  buffer 

V 

long  height;  /*  height  in  pixels  of  the  message 

buffer  */ 

}; 

typedef  struct  messbuf  MESSBUF;  /*  define  type  MESSBUF 
(need  one  of  these  for  every  defined  message  buffer)  */ 


Figure  4.2  Structure  that  Defines  Message  Buffer  Window 


text.  In  the  routine  createmessbuf ,  memory  is  dynamically 
allocated  to  accommodate  the  structure  and  values  are  read 
in  for  the  size,  location,  and  color  of  the  window.  Then 
the  ring  buffer  is  created.  The  code  in  Figure  4.3  shows 
how  the  ring  buffer  is  set  up.  For  the  number  of  lines 
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/*  we  are  going  to  build  a  circularly  linked  list  with  links 
in  only  1  direction. 

*/ 

/*  say  there  is  no  previous  guy  */ 
prev  =  (LINEINBUF  *)NULL; 

/*  build  the  list  backwards  */ 
for(i=0;  i  <  ilines;  i=i+l) 

{ 


temp  =  prev;  /*  hold  the  previous  guy’s  loc  */ 

/*  get  space  for  this  line. 

if  i  ==  0,  this  guy  is  the  last  link  of  the  list. 

*/ 

prev  =  (LINEINBUF  *)malloc(sizeof (LINEINBUF) ) ; 

if (i  ==  0) 

{ 


/*  save  prev  as  lastline  of  the  buffer  */ 
mess->lastline  =  prev; 


} 

/*  set  the  next  field  at  held  previous  guy  */ 
prev->next  =  temp; 

/*  get  space  for  the  line  of  text  plus  1  */ 
prev->ptr  =  (char  *)malloc( (ichars+l) ) ; 

/*  stick  chars  into  the  string  */ 
strcpy (prev->ptr, "" ) ; 

}  /*  endfor  all  lines  in  the  buffer  */ 

/*  at  the  end  of  the  for  loop,  prev  ==  1st  line.  */ 
mess->topline  =  prev; 

/*  must  make  last  line  point  back  at  first  line  */ 
mess->lastline->next  =  mess->topline ; 


Figure  4.3  Code  for  Constructing  Ring  Buffer 


specified,  memory  is  allocated  for  the  LINEINBUF  structures. 
The  first  structure  created  gets  the  lastline  pointer.  As 
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the  routine  cycles  through  the  loop,  it  also  allocates  space 
for  text  and  initializes  text  fields  to  empty  characters. 
The  topline  pointer  is  set  to  the  last  structure  created, 
and  then  the  lastline  next  pointer  is  directed  at  the 
topline  node,  thus  completing  the  ring.  The  window  and  ring 
buffer  are  then  ready  for  display. 

The  display  routine  sets  the  message  buffer  window  as 
the  current  graphics  window,  then  clears  the  background  and 
draws  the  window  border.  The  routine  then  cycles  through 
the  ring  buffer  list  and  subsequently  displays  each  line  of 
text  as  saved  in  each  LINEINBUF  structure.  The  display 
routine  is  called  once,  near  the  end  of  the  main  driver 
program.  This  means  that  lines  added  to  the  message  buffer 
routine  outside  the  main  driver  are  not  displayed  until  the 
return  to  main. 

Adding  a  line  of  text  to  the  ring  buffer  for  display  in 
the  message  buffer  window  is  mostly  a  matter  of  manipulating 
the  topline  and  lastline  pointers.  This  code  is  shown  in 
Figure  4.4.  The  topline  pointer  is  advanced  to  the  next 
node  in  the  list.  The  lastline  pointer  is  also  advanced  to 
the  next  node  in  the  list,  which  is  the  old  position  of 
topline.  New  text  is  then  copied  into  the  ptr  field  of  the 
node  pointed  to  by  lastline.  This  has  the  effect  of  wiping 
out  the  old  text,  which  was  the  previous  first  line,  and 
replacing  it  with  new  text  in  a  line  at  the  bottom. 
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addlinetomessbuf (mess, str) 

MESSBUF  *mess;  /*  ptr  to  message  buffer  */ 
char  str[];  /*  character  string  */ 


/*  push  topline  ahead  to  next  guy  */ 
mess->topline  =  mess->topline->next ; 

/*  push  lastline  ahead  to  next  guy  */ 
mess->lastline  =  mess->lastline->next ; 

/*  stick  in  the  line  at  lastline  */ 
if (strlen(str)  <=  mess->nchars) 

{ 

strcpy (mess->lastline->ptr , str) ;  /*  just  stick  in  the 

string  */ 

} 

else 

{ 

/*  only  copy  the  first  bytes  up  to  the  end  of  the  line 
available  */ 

strncpy (mess->lastline->ptr, str ,mess->nchars) ; 

} 


} 


Figure  4.4  Adding  a  Line  of  Text  to  the  Ring  Buffer 
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V.  NPS  INTERFACE  BUILDER  OUTPUT 


The  NPS  IB  program  produces  two  forms  of  output.  One 
type  of  output  is  a  "C"  language  graphics  program  skeleton 
that  can  be  integrated  with  the  user's  application  program 
to  produce  a  whole  software  system.  The  second  type  of 
output  is  an  ASCII  file  that  lists  all  graphics  information 
saved  for  a  particular  interface.  The  information  saved  in 
the  ASCII  file  can  be  read  back  into  the  NPS  IB  program, 
thus  enabling  a  user  to  re-edit  a  previously  constructed 
interface. 

A.  SAVING  INFORMATION  TO  OUTPUT  FILES 

When  the  user  elects  the  save  option  from  the  main  menu, 
the  main  driver  portion  of  the  program  calls  routine  save- 
design  to  create  both  output  files.  The  savedesign  routine 
is  located  in  the  file  save.c.  The  savedesign  routine 
obtains  a  user-input  file  name  by  calling  the  keyboard 
routine  for  user  input,  and  then  allocates  memory  and  opens 
two  files  for  writing.  The  user-input  file  name  is  appended 
with  a  " .c"  extension  and  is  given  to  the  file  intended  for 
use  as  a  "C"  language  program.  An  unaltered  version  of  the 
user-input  file  name  is  given  to  the  ASCII  output  file. 
Naming  the  files  in  this  manner  relieves  a  user  from  the 
burden  of  remembering  two  totally  different  file  names. 
Addition  of  the  ".c"  extension  to  the  name  for  the  "C" 
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language  output  file  facilitates  the  compilation  and 
execution  of  that  file  by  eliminating  the  need  to  copy  from 
a  file  without  a  ".c”  extension  to  a  file  with  a  "  .c" 
extension. 

After  opening  both  files,  the  routine  proceeds  to  write 
information  to  those  files.  The  "C"  language  output  file 
gets  a  global  include  line,  routine  name,  and  declaration  of 
variables.  The  ASCII  output  file  gets  comments  and 
coordinates  for  the  size  of  the  design  window.  The  routine 
then  enters  four  consecutive  loops  that  traverse  the  linked 
lists  and  write  the  information  from  the  lists  to  the  output 
file.  Sample  code  for  this  is  shown  in  Figure  5.1.  For  the 
"C"  language  output  file,  the  information  is  saved  in  the 
form  of  a  call  to  a  routine.  When  the  "C"  language  output 
file  is  linked  with  support  files,  this  routine  will  obtain 
information  from  the  call  to  create  an  array  entry  for  a 
particular  control.  The  support  routines  will  use  the 
graphics  information  saved  in  the  array  to  recreate  the 
interface  desicmed  in  the  NPS  IB  program.  The  information 
is  transferred  from  a  linked  list  format  to  an  array  format 
because  the  array  permits  faster  access  of  control  current 
values  by  eliminating  the  need  to  traverse  lists. 

When  the  linked  lists  are  traversed,  graphics 
information  is  also  saved  to  the  ASCII  output  file,  in  the 
form  of  tokens  followed  by  individual  control  values  read  in 
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/*  for  the  number  of  toggle  boxes  we  have  ...  */ 

for  (togboxcurrent  =  togboxhead?  togboxcurrent  !=  NULL; 

togboxcurrent  =  togboxcurrent->next) 

{ 

/*  increment  toggle  box  count  */ 

togboxnum++ ; 

/*  write  them  to  the  file  */ 

f print f (outf ile, "\n  maketogbutton(\"%s\H ,%f,%f,%f,%f, 

\n\t\t%f ,%f ,%d) 

togboxcurrent->title , togboxcurrent->Xcoord , 
togboxcurrent->Ycoord, togboxcurrent->llxbd,  togboxcurrent-> 
llybd,  togboxcurrent->urxbd, togboxcurrent-> 
urybd, togboxnum) ; 

fprintf  (outf  iletwo,  "V*  toggle  box  information  *V\n")  » 
fprintf (outfiletwo, "togglebox\n") ; 

fprintf (outf iletwo, "title  %s\n",togboxcurrent->title) ; 
fprintf (outf iletwo, "controlnum  %d\n" , togboxcurrent->num) ; 
fprintf (outf iletwo, "Xcoord  %f\n" , togboxcurrent->Xcoord) ; 
fprintf (outf iletwo, "Ycoord  %f \n" , togboxcurrent->Ycoord) ; 
fprintf (outf iletwo, "lowerleftxbound  %f\n" , togboxcurrent-> 
llxbd) ; 

fprintf (outf iletwo, "lowerleftybound  %f\n" , togboxcurrent-> 
llybd) ; 

fprintf (outfiletwo, "upperrightxbound  %f\n" , togboxcurrent-> 
urxbd)  ; 

fprintf (outf iletwo, "upperrightybound  %f\n" , togboxcurrent-> 
urybd) ; 

fprintf (outfiletwo, "togboxend\n\n") ; 


Figure  5.1  Code  for  Writing  from  Linked  Lists 
to  Output  Files 


from  the  linked  lists.  The  tokens  will  be  used  to  identify 
what  the  values  are  when  the  file  is  scanned  and  read  back 
into  the  NPS  IB  program. 

Saving  information  to  the  ASCII  output  file  ends  with 
traversal  of  the  last  linked  list.  The  remainder  of  the 
savedesign  routine  writes  the  rest  of  the  graphics  program 
skeleton  to  the  "C"  language  output  file.  At  the  end  of  the 
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routine,  both  the  ASCII  output  file  and  the  "C"  language 
output  file  are  closed. 

B.  SUPPORT  ROUTINES  FOR  THE  "C"  LANGUAGE  OUTPUT  FILE 

The  purpose  of  the  "C"  language  output  file  is  to 
produce  a  working  program  with  recreation  of  the  interface 
designed  with  the  NPS  IB  program.  The  "C"  language  output 
file  is  not  a  stand  alone  file,  however.  It  must  be  linked 
with  support  files  and  routines  in  order  to  operate 
correctly.  The  concept  of  this  portion  of  the  program  is 
modeled  upon  the  S  &  B  package  program.  The  user-defined 
main  portion  of  the  S  &  B  package  makes  calls  to  routines 
defined  in  separate  files  in  order  to  create  its  windows  of 
sliders  and  buttons. 

The  support  files  and  routines  for  the  NPS  IB  program 
"C"  language  output  file  are  located  in  the  files  interf ace- 
global,  h,  interfacepkg.h,  and  interfacepkg.c.  The  files 
inter faceglobal.h  and  interfacepkg.h  contain  global  constant 
and  variable  definitions.  Interf aceglobal.h  contains  mostly 
constant  definitions  for  color  and  size  of  tools.  Inter¬ 
facepkg.h  contains  global  variable  definitions  for  holding 
the  computed  size  of  controls,  positions  of  slider  buttons 
and  dial  needles,  x  and  y  boundaries  of  control  icon 
drawings,  and  other  variables  necessary  for  operation  of  the 
program.  The  file  interfacepkg.c  contains  all  the  routines 
needed  to  support  the  main  portion  of  the  program  created  by 
NPS  IB.  The  routine  maketogbutton  reads  in  graphics 
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information  for  toggle  boxes  and  enters  each  toggle  box  into 
a  toggle  box  array.  Sample  code  for  this  process  is  shown 
in  Figure  5.2.  The  routine  makevslider  reads  in  graphics 
information  about  vertical  sliders  and  enters  each  one  into 
a  vertical  slider  array.  Makehslider  is  the  routine  that 
enters  graphics  information  about  horizontal  sliders  into  a 
horizontal  slider  array.  Makedial  takes  graphics 
information  about  dials  and  reads  that  information  into  a 
dial  array.  The  routine  initvindow  sets  window  parameters 
and  attributes,  and  calls  the  routine  setcoordi-nates  to 
compute  the  values  of  global  coordinate  variables  for 
drawing  control  icons. 


maketogbutton (title , togx , togy , togllx , togl ly , togurx , togury , i- 
ndex) 

char  *title; 

f 1 oat  togx , togy , togl lx , togl ly , togurx , togury ; 
int  index; 

/*  adds  new  button  to  array  of  buttons  */ 

{ 

buttonTITLE [ index]  =  title; 
togcntrX[ index]  =  togx; 
togcntrY [ index]  =  togy; 
togllxbdf index]  =  togllx; 
togl lybd[ index]  =  toglly; 
togurxbd[ index]  =  togurx; 
togurybd[ index]  =  togury; 
buttonvalue[ index]  =  OFF; 

} 


Figure  5.2  Code  for  Entering  Information  into 
the  Toggle  Box  Array 
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The  routine  drawpicture  is  called  from  the  main  driver 
program.  Four  separate  drawing  routines,  one  for  each  type 
of  control,  are  called  from  within  drawpicture.  For-loops 
internal  to  each  drawing  routine  control  the  numbers  of  each 
type  of  control  drawn.  The  for-loop  index  provides  access 
to  the  array  of  information  for  each  control. 

Other  routines  in  the  package  include  those  that  return 
the  current  value  for  each  control,  and  those  that  cause  the 
controls  to  operate.  The  mechanism  which  runs  controls  for 
the  "C"  language  output  file  program  is  exactly  the  same  as 
that  described  for  the  NPS  IB  program  itself.  The  mechanism 
is  detailed  in  Section  I  of  Chapter  III. 

C.  THE  ASCII  OUTPUT  FILE  AND  THE  RE-EDIT  FEATURE 

The  re-edit  feature  is  selected  from  the  program  main 
menu.  The  re-edit  feature  makes  the  NPS  IB  program  more 
versatile  because  it  permits  a  user  to  read  into  NPS  IB  the 
information  for  a  previously  created  interface,  and  allows 
continuation  of  editing  on  that  interface.  A  re-edited 
interface  must  be  explicitly  saved  if  the  user  desires  to 
keep  it.  Changes  are  not  automatically  recorded  to  the 
output  files. 

Operation  of  the  re-edit  feature  is  quite  straight¬ 
forward.  The  NPS  IB  linked  lists  are  cleared  to  NULL, 
essentially  wiping  any  previous  interface  out  of  the  design 
window.  Then  the  ASCII  file  is  scanned  and  information  read 
from  the  file  is  used  to  create  new  linked  lists.  When  the 
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new  linked  list  is  traversed  by  the  program  drawing  routine, 
the  new  control  icons  are  drawn  in  the  design  window. 

Routines  in  two  separate  files  give  the  NPS  IB  program 
its  re-edit  option.  The  file  edit.c  contains  code  to  read 
in  a  file  name,  process  tokens  and  values,  and  build  the 
linked  lists.  The  file  scan.c  contains  the  routines 
necessary  to  scan  the  ASCII  file  information. 

The  format  of  the  ASCII  output  file  is  crucial  to  the 
correct  operation  of  the  re-edit  feature.  Comments  must  be 
bracketed  according  to  the  "C"  language  convention  for 
indicating  comments.  Tokens  must  always  have  the  same  name, 
and  a  token  and  its  associated  value  must  always  appear  on 
the  same  line,  separated  by  at  least  one  space.  Each  block 
of  information  for  a  control  must  end  with  a  special  token 
which  then  signals  the  editing  routine  to  process  the 
information  received.  If  the  ASCII  file  is  edited  directly 
to  improper  form,  or  if  the  user  reads  in  a  file  not  in  the 
ASCII  format,  an  error  will  occur. 

The  readfile  routine  in  file  edit.c  processes  tokens 
read  in  from  the  ASCII  output  file.  The  routine  asks  the 
scanner  to  pass  it  a  token  number,  then  switches  on  the 
value  of  the  token  to  determine  which  global  variable 
applies.  When  the  type  of  the  token  is  identified,  the 
routine  asks  the  scanner  for  another  token,  which  it  knows 
is  the  value  assigned  to  the  token  type  because  of  the 
arrangement  of  the  ASCII  output  file.  When  the  routine 
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switches  on  a  token  type  that  denotes  the  end  of  a  block  of 
information  for  a  control,  the  appropriate  processing 
routine  is  called  to  dynamically  allocate  memory  for  a 
record  structure  and  to  enter  control  attributes  into  the 
record.  Linked  list  maintenance  is  also  taken  care  of  in 
the  processing  routines.  These  routines  are  also  located  in 
the  file  edit.c. 

The  scanner  routines  are  located  in  the  file  scanner. c. 
The  routine  fill_linebuf  performs  file  input/output  by 
reading  from  the  file  into  a  line  buffer.  As  long  as  the 
line  buffer  is  filled  with  input  from  tne  file,  the  routine 
nexttok  can  process  input.  It  does  this  by  returning  token 
codes  to  the  routine  gettoken  based  on  characters  seen.  A 
space,  for  example,  is  ignored  and  thus  the  routine  returns 
a  zero  to  gettoken.  A  letter  on  the  other  hand,  is  a 
legitimate  character,  and  the  code  for  an  identifier  is 
returned  to  gettoken  for  further  processing.  In  gettoken, 
an  identifier  token  is  compared  against  a  list  of  specially 
selected  tokens.  If  the  identifier  token  matches  a  token  in 
the  list,  the  identifier  token  takes  on  the  value  of  the 
token  in  the  list.  This  value  is  then  returned  to  the  read- 
file  routine. 
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VI.  CONCLUSIONS.  LIMITATIONS.  AND  FUTURE  WORK 


The  NPS  IB  provides  graphics  students  at  NPS  with  a 
simple  interface  builder  for  application  programming.  It  is 
quick,  easy  to  learn,  and  easy  to  use.  An  application 
programmer,  for  example,  can  use  NPS  IB  to  create  a  graphics 
program  that  opens  a  window  and  draws  three  sliders  in  less 
than  five  minutes.  Yet,  the  NPS  IB  falls  far  short  of  goals 
and  expectations  envisioned  for  the  original  project. 
Although  the  basic  functionalities  of  the  program  are 
successfully  implemented,  the  program  lacks  detailed  control 
icon  drawings  and  routines  which  would  give  the  user  more 
freedom  and  flexibility  to  create  professional-looking 
interfaces.  An  interface  builder  should  be  flexible  enough 
to  permit  a  user  to  accomplish  almost  any  action  he  can 
think  to  perform.  The  NPS  IB  fails  on  this  point. 

Programming  an  interface  generator  is  a  complex  and 
difficult  task.  To  provide  a  user  with  maximum  detail  and 
functionality,  the  complexity  of  the  program  seems  to 
increase  proportionately.  David  Tristram  of  NASA  Ames 
writes  that  it  took  him  nearly  a  year  and  one-half  to 
develop  and  implement  his  panel  package  [Ref.  5].  His 
result  is  a  slick  and  professional-looking  product  with 
endless  possibilities.  But  even  his  program  has  its 
limitations.  It  lacks  an  interactive  capability,  and 
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requires  a  fairly  good  understanding  of  the  "C"  programming 
language  to  use.  To  develop  a  really  useful  interface 
generator  for  the  IRIS  workstations,  the  capabilities  of  the 
NPS  IB  program  must  eventually  be  melded  with  a  product  such 
as  the  NASA  Amrs  Panel  Package.  Since  such  a  product  was 
the  original  goal  of  this  study,  perhaps  the  current  state 
of  the  NPS  IB  can  be  viewed  as  a  foundation  work  towards 
what  might  one  day  be  a  more  powerful  and  productive 
interface  generator  for  the  Silicon  Graphics  IRIS 
workstation. 

A.  CONCLUSIONS  AND  LIMITATIONS 
1.  •  Controls 

The  NPS  IB  limits  a  user  to  three  choices  of 
controls — a  togglebox,  a  dial,  and  two  versions  of  a  slider. 
These  controls  are  the  most  basic  ones  found  in  graphics 
programs,  and  as  such,  the  selection  of  controls  provided  by 
NPS  IB  should  be  adequate  for  the  majority  of  programmers. 
Many  additional  types  of  controls  are  possible,  however,  and 
could  easily  be  included  in  the  NPS  IB  selection.  A  larger 
inventory  of  controls  would  make  NPS  IB  a  much  more 
versatile  tool. 

In  addition,  NPS  IB  limits  a  user  to  a  single  icon 
representation  of  each  control.  This  is  perhaps  the  single 
greatest  restrictive  feature  of  the  NPS  IB  program.  Many 
versions  of  toggleboxes,  dials,  and  sliders  are  possible, 
through  variation  of  shape  and  size.  The  user  should 
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either:  (1)  be  able  to  pick  and  chose  icons  of  proper  shape 
and  size  from  an  expanded  control  palette,  or  (2)  be  able  to 
alter  the  shape  or  size  of  the  control  interactively  after 
selecting  the  control  from  the  palette  window.  This  would 
allow  for  greater  user  creativity  in  designing  interfaces 
and  would  ultimately  result  in  greater  satisfaction  for  the 
user  overall. 

2 .  Color 

The  NPS  IB  program  currently  uses  a  repertoire  of 
six  colors  to  draw  window  backgrounds  and  control  icons. 
The  user  is  limited  to  an  interface  designed  in  five  colors, 
unless  he  edits  the  color  portion  of  the  interface  output 
file  directly.  This  should  not  be  necessary,  however.  Just 
as  a  user  should  be  permitted  to  select  shape  and  size  of 
controls,  he  should  be  allowed  to  adjust  color  as  well.  The 
NPS  IB  program  should  permit  the  user  to  utilize  any  color 
combinations  that  the  IRIS  workstation  provides.  The  NPS  IB 
program  does  the  user  a  great  disservice  in  preventing  him 
from  exercising  the  color  capabilities  of  the  IRIS  machine. 

Like  shapes  and  size,  color  can  help  to  distinguish 
variation  among  various  types  of  controls.  Choice  of  color 
scheme  for  an  interface  can  also  be  a  critical  design  issue 
for  an  application  programmer.  Lack  of  color  adjustment  on 
part  of  the  NPS  IB  is  another  serious  deficiency  of  the 
program.  A  mechanism  for  adjusting  color  in  the  NPS  IB 
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would  contribute  greatly  to  user  creativity  and 
satisfaction. 

3 .  Icon  Labelling 

The  NPS  IB  program  labels  each  togglebox  with  its 
user-input  name  and  each  dial  and  slider  with  its  user-input 
name  and  current  value.  For  a  togglebox,  the  name  label  is 
aligned  to  the  right  of  and  even  with  the  bottom  of  the  icon 
itself.  For  dials  and  sliders,  the  name  label  is  centered 
on  the  vertical  axis  of  the  control  and  placed  directly  over 
top  of  the  icon  drawing.  The  current  value  of  dials  and 
sliders  is  also  centered  on  the  vertical  axis  of  the  control 
but  is  placed  directly  beneath  the  icon  drawing.  The  NPS  IB 
limits  the  user  to  these  label  placements.  Provisions  for 
interactive  placement  of  labels  and  additional  text  would 
make  the  NPS  IB  program  a  more  flexible  tool  for  designing 
user  interfaces. 

B.  FUTURE  WORK 

Future  work  on  the  NPS  IB  should  be  directed  in  two 
basic  areas.  The  first  area  involves  the  development  of  an 
increasea  control  icon  inventory  and  addition  of  program 
routines  which  would  alleviate  program  limitations  and  user 
restrictions  discussed  in  Section  A  of  this  chapter.  The 
second  area  concerns  improvements  to  the  user  interface  of 
the  NPS  IB  itself. 
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L.  Expanded  Inventory  of  Controls 

Work  in  this  area  should  focus  upon  building  a 
library  of  controls,  to  include  such  things  as  palettes, 
pucks,  checkboxes,  radio  buttons,  meters,  and  strip  charts, 
as  well  as  different  varieties  of  toggleboxes,  dials,  and 
sliders.  Ideas  can  be  drawn  from  the  user  interface 
features  of  the  Macintosh  or  NeXT  computers,  or  from  SIGRAPH 
videotapes,  or  even  from  David  Tristram's  Panel  Package. 
The  control  inventory  might  also  include  useful  interface 
features  such  as  a  file  finder,  input  boxes  for  text,  and  a 
message  buffer  similar  to  the  one  displayed  by  NPS  IB.  The 
icons  representing  these  functionalities  could  be 
interactively  placed  in  the  design  window  by  the  user,  in 
the  same  way  that  controls  are  placed  in  the  design  window 
now. 

2 •  Adding  Controls  to  NPS  Interface  Builder 

Adding  a  control  to  NPS  IB  is  currently  a  multistep 
process.  The  first  step  involves  creating  a  data  record 
which  will  hold  all  the  pertinent  graphics  information  about 
the  control.  The  next  step  is  to  draw  the  control  icon  in 
the  control  palette  window.  The  third  step  is  to  make 
appropriate  changes  to  files  in  the  NPS  IB  program  which 
will  draw  the  control  to  the  design  window  (draw.c)  ,  save 
the  graphics  information  for  the  control  (process. c) ,  permit 
the  control  to  be  moved  or  deleted  (move.c),  permit  the 
control  to  be  operated  (run.c),  and  which  will  write  the 


63 


graphics  data  for  the  control  to  an  output  file  (save.c)  . 
Steps  one  and  two  are  not  complicated,  but  step  three 
involves  quite  a  bit  of  work.  A  simpler  method  of  adding 
controls  to  NPS  IB  needs  to  be  devised,  especially  if  the 
inventory  of  controls  is  to  be  greatly  expanded.  Perhaps 
one  method  of  simplifying  the  process  of  adding  controls  to 
NPS  IB  would  be  to  restructure  the  program  so  that  any  and 
all  changes  would  be  confined  to  one  file  or  module.  This 
would  save  time  and  effort  by  reducing  the  overhead  needed 
to  access  many  different  files  or  modules  for  change. 

3 .  Interactive  Size.  Shape,  and  Color  Adjustment 

To  allow  a  user  greater  control  over  the  appearance 
of  an  interface  created  with  NPS  IB,  routines  should  be 
added  to  the  program  to  permit  interactive  size,  shape,  and 
color  adjustments  to  controls.  Sizing  and  shaping 
mechanisms  might  be  patterned  after  those  used  by  the  Sun 
workstation  Framemaker  program  or  after  Apple  Macintosh 
programs  like  Macdraw.  A  color  adjustment  mechanism  might 
employ  the  IRIS  workstation's  own  cedit  program.  Any 
changes  to  size,  shape,  or  color  generated  by  these  routines 
would  then  be  saved  to  the  data  record  for  that  control  and 
subsequently  written  to  the  NPS  IB  output  file. 

4 .  Improving  Interface  of  NPS  Interface  Builder 

One  oft-repeated  rule  of  interface  design  is  that  a 
program  should  help  prevent  a  user  from  committing  errors. 
Unfortunately,  this  rule  is  not  often  followed  in  the  NPS  IB 
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program.  Although  the  message  buffer  window  attempts  to 
assist  a  user  by  offering  instructions  and  verification 
information,  many  user  actions  are  immediately  implemented 
by  the  program  without  seeking  confirmation.  This  flaw  in 
the  program  could  allow  a  user  to  mistakenly  delete  a 
control,  and  could  force  him  to  repeat  the  process  of 
selecting,  naming,  and  placing  the  control  over  again. 
Further  work  in  this  area  would  involve  the  implementation 
of  confirmation  windows  or  messages  which  would  give  the 
user  pause  to  consider  his  action  and  would  permit  him  to 
back  out  of  the  action  if  so  desired. 
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